1. Technical Field
This disclosure relates generally to web application security and in particular to a method and system for managing security constraints in a web application environment.
2. Background of the Related Art
The Java™ Platform, Enterprise Edition (Java EE) standard supports the notion of declaring security constraints for Web-based applications using XML (outside of the application code). In addition, JEE standards put the control of security into a container, which removes the control of security from the application developer. Application developers are looking for an easier ways to declare these constraints during the development process. To this end, the Java JEE Servlet 3.0 specification (Java specification: JSR315) resolves this issue by using security “annotations.” An “annotation” is a programming mechanism and, in particular, a standard way to include supported security behaviors while allowing source code and configuration files to be generated automatically. With the introduction of this specification, there are now two (2) ways to declare security constraints, namely, using a web application configuration file (web.xml), and using annotations. Moreover, annotations may be specified statically or dynamically. The static security annotations are resolved when the application is deployed, and the dynamic security annotations are resolved after the application is started.
When invoking annotations in this manner, it is necessary that a proper order of precedence by maintained. The precedence order is as follows: the security constraints declared in the XML take precedence over the dynamic and static security annotations, and the dynamic security annotations in turn take precedence over the static security annotations. If, however, metadata (for the properties in the XML security constraints and annotations) is not provided, there is no way to determine where a particular property originates if a merge (of these constraints) occurs at install time.
A known, simple solution to handling these different types of security constraints is to merge all of the security annotations once at application deployment, and once again at application start. The disadvantage of this solution is that data may not be merged correctly (i.e. the order of precedence is not maintained) because the origin of a particular property is not known with certainty. An alternative solution is to merge all of the security constraints once at runtime. The disadvantage of this solution is that a complete list of security roles defined in a servlet (whether specified through web.xml security constraints, or static security annotations) is not available at application deploy time. Thus, the entity deploying the application is not able to map a user to a certain security role.
There remains a need to handle correctly security constraints during application deployment that preserves the intent of the application developer who has declared those security constraints.